GNOME 3.26 est sorti le 14 septembre dernier. C’est la quatorzième version de GNOME 3 ! Son nom de code est Manchester et fait référence au lieu de tenue de la dernière conférence annuelle (GUADEC), où les participants ont pu souffler les vingt bougies de l’environnement de bureau libre !
Parmi les nouveautés, citons des raffinements pour le Shell, une centre de contrôle revu en profondeur, de nouvelles fonctionnalités et – surtout ! – la gestion des emojis en couleur.
Vous verrez également, en parcourant le détail des nouveautés, que le dernier Google Summe of Code (alias GSoC) a été particulièrement fructueux pour notre environnement de bureau favori.
Sommaire
- Retour sur la dernière conférence GNOME
- Le Shell (graphique) à l’honneur
- Retour sur le cycle de développement
- Vitalité du projet
- Autour de GNOME
- La suite
Retour sur la dernière conférence GNOME
Nous l’avions annoncé dans la dépêche précédente, l’édition 2017 du GUADEC célébrait les vingt ans de l’environnement de bureau libre. Avec plus de 200 personnes cette année, cette édition a été bien plus fréquentée que les précédentes : l’édition précédente comptait 160 participants. Les différentes présentations ont été enregistrées et mises en ligne sur YouTube (de Google).
Parmi les présentations, plusieurs traitent des nouvelles possibilités qui s’ouvrent aux développeurs et développeuses pour améliorer l’expérience utilisateur de leurs applications. Celles‐ci sont notamment permises par d’importantes contributions des salariés d’Endless qui poussent GTK vers sa version 4, avec un système de mise en page plus souple, des performances améliorées, etc. La bibliothèque libdazzle de Christian Hergert (créée à partir du code de Builder) peut également valoir le détour, car elle permet des transitions qui facilitent la compréhension des changements survenant à l’écran et donnent une impression de fluidité. Cela devrait permettre des animations du type de celles qu’on retrouve sur le site tympanus.net.
Pour voir en quoi consistent ces nouveautés et leurs raisons d’être, nous vous proposons cette sélection de vidéos (en anglais) de 25 minutes chacune :
- Martin Abente Lahaye — Fantastic Layouts And Where To Find Them ;
- Jakub Steiner — The Inbetweens — Why transitions matter ;
- Tobias Bernard — Building interfaces from the future.
Le Shell (graphique) à l’honneur
Le Shell connaît une série de changements et un évènement qui mérite largement que l’on s’y attarde ! Rappelons que c’est le gestionnaire de bureau, qui permet de passer d’une application à l’autre, consulter les notifications, changer de réseau, etc.
La vue globale accorde plus de place aux fenêtres. Cela a été rendu possible en réduisant les décorations (on fait disparaître le titre de la fenêtre) et en masquant la liste des bureaux virtuels. Le barre du haut se fait elle aussi discrète, en devenant translucide. Les fenêtres peuvent désormais apparaître dans la vue globale sans forcément être réduite au passage. Par exemple, une fenêtre de 400 pixels de large sur le bureau continuera de faire 400 pixels de large dans la vue globale, alors qu’avant elle était réduite à 70 %.
Comme vous pourrez le voir sur cette vidéo, de nouvelles animations font leur apparition. Pour les opérations de redimensionnement donc, mais aussi de réduction ou maximisation des fenêtres.
Rares Visalom (raresv), dans le cadre du GSoC, a amené différentes améliorations au Shell, comme lors d’une recherche avec le Shell dont l’interface permet dorénavant de lancer des actions, comme éteindre l’ordinateur, le mettre en veille ou verrouiller l’écran. Plus généralement le Shell affiche à présent plus de résultats lors d’une recherche : certains pourront trouver le résultat visuellement chargé.
Voici pour les fonctionnalités et l’agrément visuel. Sous le capot, toutefois, le Shell peine parfois à masquer son ancienneté, grevant la performance de l’ensemble sous Wayland.
Suite à la décision de Canonical de virer du monde d’abandonner l’environnement de bureau Unity, la prochaine version d’Ubuntu qui sortira en octobre s’appuiera sur GNOME Shell. Certains développeurs de la distribution avaient d’ailleurs participé au GUADEC afin de collaborer avec ceux de GNOME.
Didier Roche a largement communiqué sur ce sujet à travers une longue série de billets de blogs, qu’on vous laisse parcourir depuis le premier jour jusqu’au treizième, qui vient de sortir. On y apprend notamment que l’utilisateur pourra choisir depuis l’écran de connexion (GDM) la session qu’il souhaite ouvrir. Il pourra basculer simplement d’un Shell qui reprendra un certain nombre de codes visuels et ergonomiques d’Unity (comme on peut le voir sur la capture d’écran plus haut) à un Shell sans les surcouches qui font l’identité d’Ubuntu. Autant dire que la nouvelle a été plutôt bien accueillie par la communauté GNOME !
Retour sur le cycle de développement
Si les notes de version présentent les changements les plus importants, elles ne rentrent pas dans le détail. Nous vous proposons ici une liste de billets issus des blogs des développeurs, qui nous font part de leurs travaux durant ces six derniers mois.
Pour tous les utilisateurs et utilisatrices
- Les paramètres peuvent être configurés à travers une toute nouvelle interface ;
- Disques permet à présent de réparer ou redimensionner vos partitions, comme résultat du travail de Kai Lüke, dans le cadre du GSoC ;
- Agenda permet de créer de manière facile et puissante des événements récurrents (comme c’était déjà possible, mais avec Evolution), comme résultat du travail de Yash Singh, dans le cadre du GSoC ;
- Web offre à présent la synchronisation des signets, de l’historique, des mots de passe et des onglets à travers différentes instances en s’appuyant sur Firefox Sync ;
- Nautilus voit l’intégration de Nextcloud arriver comme résultat du travail de Julius Härtl (juliushaertl), dans le cadre du GSoC ;
- Cartes reçoit quelques raffinements ;
- Musique accélère !
- Jeux améliore sa gestion des collections et des manettes. Son mainteneur Adrien Plazas avait donné une interview à LinuxFr.org, il y a quelques mois !
Des améliorations aussi pour les développeuses et développeurs
- Builder continue de s’améliorer.
Indispensable : des emojis en couleur !
Jusqu’à présent, une extension pour GNOME Shell facilitait l’ajout d’emojis, mais sans la couleur. Avec GNOME 3.26, la combinaison de touches Ctrl
+ Maj
+ E
vous permet dorénavant d’accéder à tout moment à un sélecteur d’emojis en couleur, pour peu que vous ayez une police de caractères ad hoc installée (par exemple, EmojiOne ou Noto Color Emoji) ! Les applications peuvent également décider d’incorporer un sélecteur d’emojis, et c’est le cas de Polari 3.26 !
Cette fonctionnalité a nécessité des modifications au cœur de GNOME, dans GTK+, Cairo (version 1.15.8), fontconfig et Pango. Plus d’informations sur ce billet de blogue.
Vitalité du projet
Intégration dans les distributions
Michael Catanzaro avait fourni précédemment (à l’occasion de la version 3.22) quelques recommandations à l’attention des distributions sur les logiciels à privilégier ou éviter par défaut. Voici la liste mise à jour à l’occasion de la 3.26.
Le même Michael Catanzaro avait précédemment tiré la sonnette d’alarme sur le fait que les distributions ne prenaient pas la sécurité suffisamment au sérieux, en incluant des versions obsolètes de WebKitGTK+ (qui motorise différentes applications comme Web, mais aussi Evolution, Empathy, Bijiben, etc.). Des progrès ont été remarqués depuis.
Monétisation du développement
Un bon moyen de s’assurer de la vitalité du projet est de permettre à ses participants d’y consacrer un maximum de temps en reconnaissant leur travail par de la monnaie. Un bouton de donation a été intégré dans le gestionnaire de logiciels, mais cela reste extrêmement rudimentaire : un simple lien vers une page de donation sur le site Web du développeur. Ça pose d’énormes difficultés car chaque développeur propose un nombre restreint de systèmes de paiement (Flattr, Patreon, Bitcoin, Paypal…) et les utilisateurs n’ont pas toujours un compte sur ces systèmes. De plus, ils doivent faire la démarche d’aller de temps en temps payer pour tel ou tel logiciel, et même les âmes les plus militantes ne font pas cet effort. Une proposition a été faite par Joaquim Rocha pour mettre en place un système d’abonnement qui permettrait de redistribuer les sommes en fonction du taux d’utilisation des logiciels et des préférences des utilisateurs. Ça s’appelle TrinkGeld et ça a donné lieu à de beaux débats (voir les commentaires sur le blog de l’auteur).
L’une des difficultés du bouton « donation » que TrinkGeld ne résout pas est que c’est destiné principalement aux applications graphiques. Ça ne couvre pas directement le travail sur les bibliothèques et les dépendances, dont les développeurs doivent alors chercher d’autres moyens de financement. C’est le cas, par exemple, de Sébastien Wilmet, qui vient de lancer une campagne de financement sur Liberapay pour poursuivre ses efforts sur GtkSourceView, ainsi qu’il en parle lui‐même dans nos colonnes.
Autour de GNOME
Pitivi s’approche de la version 1.0
Fabian Orccon (cfoch), Stefan‐Adrian Popa (stefanzzz) et Suhas Nayak (suhas2go) ont tous trois œuvré sur le logiciel de montage vidéo Pitivi dans le cadre du Google Summer of Code 2017. Leur cahier des charges est résumé sur le blogue de Pitivi et leurs progrès sont développés sur leurs blogues respectifs. À noter que certaines fonctionnalités ne seront intégrées qu’une fois la 1.0 sortie, la priorité actuelle étant de peaufiner l’existant (ce à quoi Stefan‐Adrian Popa a pu s’atteler, ayant complété son cahier des charges en avance !).
Quoi qu’il en soit, il y a quelques jours à peine paraissait la 1.0 Release Candidate (billet de blogue). Que de chemin parcouru pour ce projet débuté en 2004 !
Pour suivre au plus près les évolutions du projet, rappelons que le Planet Pitivi relaie les nouvelles et que des paquets Flatpak sont à disposition (de la version stable comme de la version de développement) !
LibreOffice
Caolán McNamara continue d’œuvrer à améliorer le rendu avec GTK+ 3 de la célèbre suite bureautique libre et multi‐plate‐forme, avec cette fois‐ci un rendu des transitions OpenGL sans coupure. À noter que la vidéo de démonstration est faite sous Pitivi. ;)
En très très bref
NetworkManager 1.8, GStreamer 1.12 et Shotwell 0.27 sont sortis, ainsi que la version 2.9.6 de GIMP, qui contient d’importants changements.
Ah, et tant qu’on parle de GIMP, Jehan a récemment publié une dépêche narrant le travail en cours sur ZeMarmot, GIMP et GIMP Motion (greffon d’animation pour GIMP).
La suite
Cet article visait à informer sur l’actualité de GNOME, et éventuellement sur les changements logiciels majeurs. On fera de nouveau le point dans six mois (de bien belles évolutions en perspective : Pipewire, « quarter tiling » et autre prise en main à distance à travers Wayland). Si vous désirez participer, rejoignez‐nous dans l’espace de rédaction collaborative du site !
Pour participer à la rédaction ou la traduction des notes de versions de GNOME, il est également possible de contribuer, mais c’est dans GNOME qu’il faut s’impliquer.
Aller plus loin
- Notes de version pour GNOME 3.26 (498 clics)
- Annonce de la sortie de la version 3.26 (80 clics)
- La vidéo de présentation des nouveautés (1 min 51 s) (251 clics)
- Dépêche précédente, à l’occasion de la version 3.24 (58 clics)
# Belle évolution
Posté par lanargeek . Évalué à 2.
C'est des petits détails mais ça fait beaucoup quand on utilise ce genre de DE. Faut espérer que le changement ne sera pas trop dur pour les utilisateurs actuels d'unity, y a quelques petites habitudes qui vont traîner :D
Dommage que mon pc n'ait pas assez de mémoire vive pour gnome et que justement gnome soit trop dépendant de systemd (je suis sur une antix, avec sysvinit donc).
# Gnome...
Posté par alex666 . Évalué à 8.
Wow!!! Impressionnal tout autant que fondamentant.
[^] # Re: Gnome...
Posté par antistress (site web personnel) . Évalué à 10.
[^] # Re: Gnome...
Posté par windu.2b . Évalué à 0.
C'est une révolution ! Il faut tout racheter !!!
[^] # Re: Gnome...
Posté par Obsidian . Évalué à 3.
Indubitablement disruptif, en effet.
# Flatpak
Posté par ff9097 . Évalué à 3.
J'espère que flatpak va bien se démocratiser. Histoire de séparer
applications et bureau.
[^] # Re: Flatpak
Posté par Albert_ . Évalué à 10.
Ouhais enfin c'est pas tres elitiste tout de meme flatpak, ca coute rien et c'est pas complique a utiliser. Il commence meme a y avoir des GUI pour rajouter des logiciels.
MAIS et c'est un gros mais j'espere que cela ne va pas devenir la norme et j'espere que ce qui fait la force de linux depuis des dizaines d'annees (les systemes de paquets) seront encore utilise car je n'ai pas un disque dur de taille infinie sur mon laptop!
[^] # Re: Flatpak
Posté par ff9097 . Évalué à 2.
ça tombe bien il y a ce qu'il faut pour pas remplir ton DD
[^] # Re: Flatpak
Posté par Albert_ . Évalué à 6.
Toi tu n'as jamais regarde la taille que flatpak prenait…
J'ai eu la surprise d'avoir ma partition / pleine (pas le home) et quand j'ai regarde ce que c'etait quel surprise de voir que le responsable etait flatpak…
Note pour plus tard, lors d'une prochaine installation mettre le repertoire /var/lib/flatpak dans une GROSSE partition.
[^] # Re: Flatpak
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
Il était peut être mal fait. Pour un certain nombre de projets, c'est encore tout nouveau, limite expérimental.
Ensuite, il y a la question des runtimes. D'installer le runtime qui va bien pour GNOME ou KDE, ça va prendre de la place. Pour une seule application, t'auras l'impression que c'est beaucoup trop. Mais ensuite, plus t'installeras d'applications qui dépendront du même runtime, moins ça paraîtra problématique.
[^] # Re: Flatpak
Posté par Albert_ . Évalué à 5. Dernière modification le 26 septembre 2017 à 17:43.
Merci j'avais bien compris, mais bon flatpak le but c'est un peu d'isoler chaque application si à la fin c'est pour se retrouver avec un runtime qui fait tourner toute tes applications autant se servir du système de paquets de ta distribution. Enfin c'est mon avis.
L'intérêt que vois c'est pouvoir tester des logiciels plus à jour que celui de la distribution sans tout casser ou certains logiciels proprio que je préfère isoler (Spotify pour ne pas le nommer).
[^] # Re: Flatpak
Posté par antistress (site web personnel) . Évalué à 3.
Je ne suis pas expert mais, de ce que je comprends, "un seul runtime" n'est pas incompatible avec "isolation des applis" (qui se fait avec les dernières technos du noyau et de GNOME).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par Maclag . Évalué à 5.
Si je comprends bien, un runtime, c'est une mini distro dans la distro?
Est-ce qu'il n'y a pas un risque de retrouver les mêmes problèmes en fin de compte?
Les runtimes sont gérés comme des ensembles de paquets, qui auront leurs mises-à-jour, qui auront besoin de tests et ainsi de suite. Combien de temps avant d'avoir de multiples versions de runtimes et des problèmes de dépendances dans les paquets?
Je vois bien l'avantage (avoir plusieurs "environnements" sur une machine sans tout mélanger). Mais quelque chose me dit aussi qu'il aurait été préférable que les distros trouvent une façon de le faire avec les paquets "classiques".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par Maclag . Évalué à 4.
Hmm…
Je me demande comment on en arrive là:
-les distros empaquètent toutes des versions différentes des mêmes bibliothèques
-c'est le bordel
-faisons un runtime de bibliothèques standards
N'est-ce pas là la résurrection du LSB?
Encore une fois: au lieu de faire un runtime, ne peut-on pas établir un jeu de bibliothèques avec un label LTS et/ou MTS (Mid-Term-Support) à destination des distros pour leur indiquer les ensembles recommandés?
Les distros sont-elles si peu coopératives qu'elles refuseraient toute proposition d'alignement dans les versions de bibliothèques?
-Si non: il "suffirait" de décider avec les distros de ce qu'on met dans les jeux MTS/LTS
-Si oui: espérons que Flatpak ait tellement de succès que ça en devienne embarrassant ("tout le monde utilise les runtimes Flatpak au lieu de celui de notre distribution!?")
Dans les 2 cas, l'existence même de Flatpak permet de mettre le sujet sur la table, ça me semble une bonne chose.
[^] # Re: Flatpak
Posté par Sufflope (site web personnel) . Évalué à 2.
Voilà.
C'est le but oui. Un peu comme docker permet (bon attention c'est pas si magique qu'il n'y parait) de lancer "tel soft dans tel runtime avec telles versions figées" peu importe ton OS pourvu qu'il puisse "faire tourner une image docker".
[^] # Re: Flatpak
Posté par Albert_ . Évalué à 1.
C'est un peu ce que j'avais compris donc si tu utilises un seul runtime tu perds la compartimentation et donc en securite et on revient au meme que si tu utilises le systeme de paquet de ta distrib.
Maintenant j'ai un peu l'impression que cela risque d'aller vers un truc ou les distribs seront minimaliste, il y aura quelques runtime principaux (gnome/KDE/…) et les distribs ne s'occuperont plus de faire des paquets cela sera a la charge des projets. Ca peux etre cool pour les distribs mais cela peut aussi mettre un sacre coup dans la place disque disponible surtout si en fait les logiciels qui ne feront pas parti des gros environnement (vlc, freecad, blender, gimp, libreoffice, …) font eux aussi leur propre runtime.
[^] # Re: Flatpak
Posté par antistress (site web personnel) . Évalué à 2.
non, pas nécessairement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par Adrien . Évalué à 3.
Perso je préfère nettement le système actuel : le rôle de « tampon » des distributions me semble très important dans un éco-système libre. Non seulement ça évite que les dev fasse n'importe quoi (par ex. un cycle de release totalement stupide), mais en plus tu peux faire des choses pour la qualité à l'échelle de la distribution, comme peut le faire Debian avec Lintian ou l'équipe en charge de la sécurité. C'est très intéressant notamment pour les petits projets, qui n'ont pas beaucoup de moyens.
En mettant le packaging sur les dev upstream, j'ai bien peur que ces projets d'amélioration de la qualité ne puissent voir le jour, et qu'à terme on se retrouve avec un éco-système tout bancal, sans aucune stabilité et ni gestion sérieuse de la sécurité.
Et honnêtement, le packaging n'est pas non plus super compliqué, à condition que le logiciel soit bien fait…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par Adrien . Évalué à 5.
C'est ce que je dis. 6 mois est un cycle bien trop court pour beaucoup de gens, notamment ceux qui gère un parc informatique ! Ubuntu LTS c'est 5 ans, Debian c'est 2 ans + 3 avec le projet LTS, RHEL ?
C'est typiquement un point de désaccord classique entre les dev, qui veulent que tout aille vite, et les autres (admin et utilisateurs), qui veulent une stabilité.
Je persiste. Faire un paquet Debian n'est pas si dur… si le logiciel de base est bien fait : bonne gestion des dépendances, copyright clair et précis, build et monté de vesions bien maîtrisés, bonne portabilité. Malheureursement il est rare de trouver des logiciels bien fait. Typiquement le problème de packaging de Owncloud est venu de la très mauvaise gestion des montées de version.
Pour ta gouverne, si tu packages pour Debian, il n'est pas forcément utile de packager aussi pour Ubuntu, puisque ce dernier reprend tel quel une bonne partie des paquets Debian (4 paquets / 5 d'après le wiki : https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers).
Une fois inclut dans Debian, ton paquet ira naturellement vers Ubuntu. Après bien sûr, si tu veux raffiner par distrib tu peux.
Tu parles de PPA, mais c'est encore une vision de dev. Pourquoi utilise un PPA lorsque ton logiciel est directement intégré dans la distrib ??
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par whity . Évalué à 2.
C’est pas la mer à boire, et surtout, en général, si tu n’arrives pas à le faire, c’est que ton appli a d’autres problèmes (comme le fait que l’installation soit trop compliquée pour être automatisée, ou le script de build trop pourri pour compiler ailleurs que sur la machine du développeur).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Flatpak
Posté par BAKfr . Évalué à 2.
Ça dépend vraiment des cas, et surtout des technologies utilisées.
Par exemple, si tu veux faire une appli graphique en Python qui utilise des ressources (images, fichier de traduction, etc.), tu t'aperçoit vite qu'il n'y a pas de moyen propre de packager cela sous debian.
J'ai un collègue qui y a passé plusieurs jours pour comprendre quels étaient les bonnes pratiques, avant de faire un script moche mais qui fait le travail. Et on parle seulement de faire un PPA, pas de l'intégrer à une distrib.
On peut ajouter à cela que la moitié des libs Python utilisée ne sont pas fournies par les distribs, et qu''il faut soit les packager aussi.
Bref, en dehors des langages compilés, c'est beaucoup plus compliqué.
[^] # Re: Flatpak
Posté par whity . Évalué à 1.
Je n’ai jamais packagé d’applis en python. Mais, si je prends un exemple au hasard, comme musicbrainz picard, qui correspond à ta description, j’ai :
Le reste est du même acabit. En fait, il n’y a rien de compliqué là-dedans.
Par contre, la plupart du boulot est fait dans le « setup.py », qui est chargé du déploiement de l’application (l’équivalent du make install). Mais… c’est juste logique, non ?
Si ton appli ne sait pas s’installer, elle ne sera effectivement pas packageable.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par Adrien . Évalué à 3.
Et bien le PPA perd beaucoup d'avantage par rapport à un dépôt de la distrib :
– gestion de la sécurité aléatoire
– intégration à la distrib aléatoire (cf debian-multimedia par ex.)
– les outils qualités de la distribution ne s'y applique pas
Pas forcément: Si le bug est connu et pas trop gênant, l'utilisateur fera avec. Le problème principal vient quand les nouvelles versions de logiciels apportent plus de bugs qu'ils n'en corrigent ! Si à ça on ajoute un cycle de release court, ça devient l'enfer pour l'utilisateur : le produit devient totalement instable !
On en revient au commentaire de maclag plus haut : à mon avis le problème se situe bien plus au niveau des cycles de release des développeurs. Avec un bon cycle de release, l'utilisateur s'y retrouve totalement, mais le packageur également, il n'y a donc aucun soucis.
[^] # Re: Flatpak
Posté par CrEv (site web personnel) . Évalué à 2.
Aujourd'hui plus personne ne veut réellement de cycles de release qui se passent en mois. Y compris sur les logiciels desktop.
Ha oui, donc en fait le vrai problème ce sont les logiciels mal fait. Soit. Mais bon avec un cycle de release long et une nouvelle version qui ajoute plus de bugs qu'elle n'en corrige c'est encore pire qu'avec un cycle court.
[^] # Re: Flatpak
Posté par Adrien . Évalué à 2.
J'ai pas compris : selon toi les gens veulent des cycles plus long ou plus court ?
Pas forcément non, mais je me suis peut-être mal exprimé. Quand je parle cycle de release, ce sont les versions majeures, mais les corrections de bugs. petit exemple calqué sur les cycles Debian :
Logiciel version 1 (géré pendant 5 ans)
- v1.1 (maintenance : correction des gros bugs, sécurité, mais pas d'apport de nouveaux trucs)
- v1.2
- v1.3
Logiciel version 2 (nouvelle version majeure, plein de nouveaux trucs tout buggé)
- v2.1 beta (correction de bugs, etc.)
- v2.2 beta
- v2.3 stable
- v2.4 maintenance
l'utilisateur va pouvoir prendre la v1, qui sera géré par ex. pendant 5 ans, puis la 2.3 gérée pendant 5 ans. Il pourra ainsi capitaliser sur le fonctionnement du logiciel, qui ne variera pas.
Avec un tel cycle très banal, l'utilisateur (et le packageur) pourra avoir un logiciel stable. Le coût du changement sera moindre, puisqu'il a lieu tous les 5 ans. De même, le packageur pourra fournir dans Debian stable la version stable, et en testing la version moins stable mais plus à jour (2.1, 2.2)
Voici un autre exemple de cycle, en type rolling release inspiré de firefox :
Le logiciel a une version « master ». Tous les 2 mois, le master fournira la version courante. Pas de LTS.
Dans ces conditions, l'utilisateur aura toujours la dernière version. Lorsque l'équivalent de la version 2 arrive, il essuyera donc les pots cassés, ainsi que les éventuels problèmes de compatibilité (ah, le fichier enregistré avec la version 2 ne fonctionne pas sur le PC du collègue, qui lui à la 1.3…)
Il devra en permanence s'adapter aux changements du logiciel (interface, etc.), ce qui est coûteux.
Le packageur quand à lui sera obligé de packager toutes les versions, notamment pour les correctifs de sécurité, ou la correction des bugs les plus gros… Le coût sera plus important, puisque le logiciel changera sans cesse.
Ces deux cycles de release sont du vécu en tant que packageur. Après entre les 2 il y a plein de situations, qui peuvent fonctionner.
[^] # Re: Flatpak
Posté par Mildred (site web personnel) . Évalué à 6.
En pratique je ne connais pas beaucoup de logiciels qui maintiennent en même temps plusieurs version en parallèle. Il faut des ressources pour se permettre de développer à la fois les nouvelles fonctionnalités de la version 2 et maintenir la version 1.
[^] # Re: Flatpak
Posté par ff9097 . Évalué à 3.
C'est quoi un cycle de release non stupide ?
C'est pas trivial, entre les deb, les rpm. Les paquets Ubuntu, Debian, Fedora et j'en passe. Entre debian 9 et 8, les deux LTS Ubuntu et la dernière non LTS, les deux dernières versions Fedora…… et pour chacune des distributions la gestion des dépendances bien galères qui te force à utiliser une certaine version de bibliothèque en particulier…. Et ça fait pas mal de cas à tester pour vérifier que ça fonctionne bien pour chaque distribution. Non c'est un système qui est dépassé.
[^] # Re: Flatpak
Posté par Adrien . Évalué à 2.
Par exemple celui de NextCloud :
https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule
Dans une organisation, un cloud peut être un élément très important, il faut donc une forte stabilité, tu va pas t'amuser à changer de versions tous les 4 matins.
Les versions sont supportés moins d'un an, et pour les dernières tu n'as même pas de date de fin de support ! Ce cycle de release n'est donc pas adapté à un milieu pro, malheureusement, hors ça semble une cible du projet quand même.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Flatpak
Posté par whity . Évalué à 2.
Parce que c’est un exemple de produit qui a un cycle de release stupide.
Si tu vises les entreprises, il faut un support de minimum 3 ans, et des migrations de version qui se font facilement. Ou alors tu ne fais que du SaaS, là tes migrations sont en interne, ton client s’en tape il paie son abonnement.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Flatpak
Posté par Albert_ . Évalué à 2.
Je suis d'accord avec toi. Je pense tout de meme que flatpak va avoir l'effet dont je parle mais je me trompe peut etre.
[^] # Re: Flatpak
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 01 octobre 2017 à 20:23.
Merci pour la bonne blague : les petits projets, ils attendent dans l'anti-chambre avec comme raison "petit projet" (rien qu'hier on m'a sorti cette "raison" pour me refuser dans un repo, alors que tout le reste était propre et pré-mâché, et j'ai mis 1 an que pour une inclusion dans Fedora alors que j'ai un packageur Fedora qui a préparé le package, soit ~350 jours de trop par rapport au besoin des petits projets, Apple a lui validé en 1 jour, 80€/an certes mais 1 jour et c'est ce qui compte).
L'upstream se fait chier à faire les package pour une très simple raison : la défaillance des distros à gérer les petits projets (même si on paye. En fait on ne peut pas payer. même si on fait du libre, n'osons pas parler de non libre), alors merci de ne pas prendre les petits projets comme exemple pour dire que les distros devraient être les seules à faire le packaging (c'est l'inverse!)
[^] # Re: Flatpak
Posté par Adrien . Évalué à -1.
Pour info, c'était quelle distribution ?
Si je prends l'exemple de Debian, que je connaît bien, il y a plein de petits projets qui trouvent leurs place, plus ou moins facilement. Je pense même qu'une majorité des paquets présent dans Debian sont des petits projets…
Ceci dit, je te rejoint tout à fait sur le fait que le critère « petit projet » ne devrait pas être discriminant, et qu'il y a du progrès à faire du côté des distributions. Mais je ne pense pas que des choses genre flatpak sont une amélioration de l'existant.
Efin il est facile de prendre un exemple qui fonctionne mal, et de généraliser à toutes les distrib et tous les petits projets sans plus de précision… C'est à mon sens un raisonnement néfaste et vicié, qui démobilise les gens, que ce soit des dev ou packageurs. Il serait probablement plus productif d'essayer d'avoir une critique constructive, avec des faits et des situations clairement établis, sur lesquelles on pourrait débattre, mais tu n'est vraisemblablement pas là pour ça.
[^] # Re: Flatpak
Posté par Zenitram (site web personnel) . Évalué à 2.
Merci pour la deuxième bonne blague : tu accuses les autres de tes propres problèmes, et tu t'étonnes ensuite qu'aucun débat constructif n'est possible.
Ce problème ça fait plus de 10 ans qu'il existe, et ça fait plus de 10 ans que les gens aimant le système actuel font l'autruche. Rien de nouveau, puisque c'est exactement ce qui est fait dans les commentaires de ce journal.
Pour un débat constructif, il faut commencer à accepter que le problème est chez soit, et ta réaction démontre tout le contraire.
En attendant, par exemple Apple a pris l'idée, a tué tous les défauts (ils valident entre 1 heure et 1 semaine suivant le pic de charge, pas de ségrégation "bouh ce n'est pas libre", par exemple), et se fait des couilles en or, pendant que les libristes s'amusent à tuer tout projet dans le sens d'une réponse au problème "parce que ce n'est pas propre" (et puis bon, se mettre d'accord c'est chiant).
Bref, les tentatives de critique constructive ont lieu souvent, encore faut-il qu'en face on soit prêt à écouter et non pas trouver une excuse pour ne pas se rendre compte qu'il y a un soucis.
Passons, rien de neuf depuis plus de 10 ans, y compris entre toi et moi.
Tu devrais balayer devant ta porte, et tu verras que tout a déjà été dit des milliers de fois sur les problèmes des repos (que ce soit pour les repos ou pour XMPP : pourquoi ça ne marche pas? Ben en fait, tout bêtement parce que vous envoyez chier les gens qui vous expliquent en quoi vous merdez, forcément sans écouter vous ne risquez pas de comprendre).
PS : je n'ai pas répondu à ta demande de précision, pour une raison bien précise : je sais très bien que même si je te le montre, tu trouveras une excuse pour ne pas accepter la critique constructive (tu as déjà commencé dans ta réponse, d'ailleurs, et je sais que tu trouveras d'autres excuses, comme il est le cas dans les commentaires de ce journal)
[^] # Re: Flatpak
Posté par Adrien . Évalué à 1.
Citation de mon message :
Ceci dit, je te rejoint tout à fait sur le fait que le critère « petit projet » ne devrait pas être discriminant, et qu'il y a du progrès à faire du côté des distributions.
Par contre, dans tes commentaires je ne vois aucune critiquesenvers les dev… J'en conclut que eux ont tout compris et n'ont aucun progrès à faire ?
Oui, mais il faut que ça fonctionne dans les deux sens ! Lorsque des dev invoque des arguements objectivement foireux (par ex. il faut obligatoirement packager pour Debian ET Ubuntu ET Linux mint), il faut se rendre compte qu'il y a un soucis, et que c'est juste du dénigrement gratuit.
À la différence de XMPP, les dépôts fonctionnent plutôt bien, et c'est bien une raison du succès de Linux sur les serveurs. D'ailleurs, je constate simplement que les systèmes d'exploitations ont pratiquement tous repris le principe des dépôts, que ce soit sous Windows, Android ou Apple…
[^] # Re: Flatpak
Posté par Renault (site web personnel) . Évalué à 7.
Non, ils ont repris le principe des Flatpaks avec une interface et un dépôt centralisé pour les récupérer.
Les applications sur iOS / macOS store, Windows store et Play Store sont tous dans des bacs à sable et contiennent l'essentiel des dépendance nécessaire (en fait toutes les dépendances sauf ce qui est fourni par le système de base).
Cela reste donc très différent. Il n'y a pas le découpage des paquets et des dépendances comme cela est fait dans la quasi totalité des distributions.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Un lecteur vidéos ?
Posté par dani . Évalué à 1.
Dommage, il ne manque plus qu'un lecteur vidéos à cet environnement. Il y avait Totem qui était pas trop mal, avant qu'il ne soit saboté il y a quelques versions (entre autre, retrait de la playlist…). Et depuis ce sabotage, il ne bouge plus. Il y en a qui s'en servent de Gnome Vidéo maintenant ?
[^] # Re: Un lecteur vidéos ?
Posté par windu.2b . Évalué à 9.
Depuis que VLC fait tout, même le café, je ne connais personne qui utilise autre chose…
[^] # Re: Un lecteur vidéos ?
Posté par dani . Évalué à 0.
Mouais. VLC fait tout, c'est bien son défaut. Moi je veux juste un lecteur multimédia simple, avec playlist. Gnome MPV semble pas mal, mais pas encore dans les dépôts de Fedora (je sais pas pour les autres distrib)
[^] # Re: Un lecteur vidéos ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 2.
Il est dispo dans le dépôt RPM Fusion. Au pire, un Flatpak est également dispo.
[^] # Re: Un lecteur vidéos ?
Posté par dani . Évalué à 1.
En effet. J'utilisais un COPR à l'époque, j'avais même pas remarqué que j'avais basculé sur la version fournie par RPMFusion. C'est donc une bonne nouvelle. J'ai plus qu'à attendre la prochaine version qui devrait intégrer le mode shuffle (indispensable pour moi)
[^] # Re: Un lecteur vidéos ?
Posté par Renault (site web personnel) . Évalué à 6.
Moi je l'utilise, il me convient très bien.
C'est très rare que j'ai besoin de recourir à VLC par exemple.
[^] # Re: Un lecteur vidéos ?
Posté par dani . Évalué à 2.
Ok, ça répond à ma question. Je me demandais si la nouvelle version pouvait convenir à certains :-)
[^] # Re: Un lecteur vidéos ?
Posté par ff9097 . Évalué à 1.
Je l'utilise mais il y a quelques petits bugs gênants
[^] # Re: Un lecteur vidéos ?
Posté par RyDroid . Évalué à 1.
Quels "petits bugs gênants" ?
[^] # Re: Un lecteur vidéos ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 6.
T'as GNOME MPV, qui fait plutôt bien le job.
[^] # Re: Un lecteur vidéos ?
Posté par antistress (site web personnel) . Évalué à 2.
Je suis d'accord : moi c'est la fonction "reprise" qui me manque. Pourtant c'est généralement Totem que j'utilise (je ne crois pas que VLC ait cette fonction d'ailleurs ?)
C'est dommage, avec l'informatique on était censé bénéficier d'une automatisation. Là il faut refaire le réglage à la main du dernier moment lu.
[^] # Re: Un lecteur vidéos ?
Posté par Strash . Évalué à 4.
VLC a cette fonction.
[^] # Re: Un lecteur vidéos ?
Posté par windu.2b . Évalué à 4.
Ça fait même 2 ans et demi que c'est intégré directement dans VLC (avant, il fallait passer par un add-on).
[^] # Re: Un lecteur vidéos ?
Posté par antistress (site web personnel) . Évalué à 2.
ha c'est rigolo, VLC a dû le gagner quand Totem l'a perdu…
[^] # Re: Un lecteur vidéos ?
Posté par Mildred (site web personnel) . Évalué à 2.
J'utilise, mais ce qui me manque le plus c'est de pouvoir ouvrir deux vidéos en même temps, pas juste la playlist.
[^] # Re: Un lecteur vidéos ?
Posté par dinomasque . Évalué à 4.
Regarder 2 vidéos à la fois, BeOS le faisait il y a 20 ans ! https://www.youtube.com/watch?v=BsVydyC8ZGQ
;-p
BeOS le faisait il y a 20 ans !
# A quand une IHM révolutionnaire ?
Posté par Olivier ROSET (site web personnel) . Évalué à -1.
Moi ça fait des années que j'utilise Linux, gnome et kde (ca dépend des machines et de mon humeur).
La puissance des cartes graphiques est gigantesque, celle des CPU, idem, et pourtant on nous ressort toujours les mêmes paradigmes dans les IHM, avec des bureaux, des icônes, des menus, des barres de taches, tout ça bien plat, bien triste, bien "old school".
Quelques timides effets 3D de ci de là.
A quand un projet d'IHM à la "wahhoouu effect" ?
Avec l'usage de toute la puissance des cartes graphiques modernes.
La 3D est à nos portes, de même que les casques à réalité virtuelle, les capteurs de mouvements, de detection et suivi du regard, faites nous rêver. :)
Je suis un adepte de l'ihm minimaliste et de la ligne de commande, mais quand même, un peu de révolution dans les IHM serait "cool". :)
J'avoue qu'une IHM avec de la 3D, des "objets" représentés en volume, manipulables facilement, un bureau avec un effet "volumique" ça pourrait être "cool".
Sérieux, dans 10 ans, on aura encore des fenêtres plates, des icônes fixes et "moches" ????
L'informatique a les moyens d'être fun aujourd'hui ou la moindre machine à une puissance phénoménale.
Si on en faisait quelque chose ?
[^] # Re: A quand une IHM révolutionnaire ?
Posté par gouttegd . Évalué à 10.
C’est pas déjà ce qu’on a tenté de faire il y a quelques années ? Avec des trucs comme « Compiz » ou quelque chose dans le genre ? Le cube 3D, les fenêtres qui s’embrasent au moment de les fermer, etc.
C’est passé de mode, non ?
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Compiz c'est plutôt quelques effets 3D ajoutés au paradigme existant (le bureau à la Windows 95). Il a l'air de plutôt parler de trucs à la Looking Glass, et même d'aller plus loin.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Olivier ROSET (site web personnel) . Évalué à 2.
Oui tout à fait.
Looking glass prenait le bon chemin.
Mais depuis, plus rien de bien innovant. :(
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Albert_ . Évalué à 4.
Il y a eu des versions de compiz avec des plugins qui permettait ce que l'on voyait dans les videos de looking glass. Comme le fait de tourner les fenetres et faire des trucs derriere (je trouve ca rigolo moi aussi).
[^] # Re: A quand une IHM révolutionnaire ?
Posté par ff9097 . Évalué à 5.
GNOME Shell a pourtant un paradigme particulier
[^] # Re: A quand une IHM révolutionnaire ?
Posté par alex666 . Évalué à 2.
Pour les malcomprenants, si tu pouvais expliciter…
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sébastien Wilmet . Évalué à 3.
À la sortie de GNOME 3.0, il y a eu beaucoup d'utilisateurs de GNOME 2 qui n'étaient pas satisfait, le paradigme du bureau avait fort changé, il fallait changer ses habitudes (ou changer d'environnement de bureau), etc.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Le Gab . Évalué à 1.
D'où vient cette vérité comme quoi tout système/application devrait se dispenser d'une phase d'apprentissage minimum???
[^] # Re: A quand une IHM révolutionnaire ?
Posté par alex666 . Évalué à 1.
paradigme: voir définition du Trésor de la Langue Française:
[http://atilf.atilf.fr/dendien/scripts/tlfiv5/advanced.exe?8;s=2991450900;]
De la phrase:
je retiens qu'il est toujours question de "bureau"…
Ce qui "justifie" la métaphore du bureau comme représentation indépassable de mon cerveau, de préférence avec les images qui renvoient au travail de bureau américain (au hasard) et les Icônes qui vont de soi et qui vont avec (dossier, meuble de bureau, etc.)
Le paradigme de Gnome 2 ou 3 est toujours le même, et donc je préfère KDE qui n'est pas génial, mais au moins un peu plus configurable.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par alex666 . Évalué à 4.
Des icônes?
Vous apprendrez pour demain par coeur les 350 icônes indispensables, variables suivant les DE et applications, avec un design révolutionnaire et tout et tout, 1000 pixels de côté…
Exemple? sauvegarder = joli dessin de disquette, objet obsolète, alors pourquoi pas un dessin de rouleau de papyrus ou de scribe taillant au burin sur granit? Au moins, ça restera clair plus longtemps que nos sauvegardes, même et surtout dans le saint Cloud !!!
Vivement l'invention de l'alphabet.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par kna . Évalué à 2.
Pas pour les applis Gnome, où tu as ça :
[^] # Re: A quand une IHM révolutionnaire ?
Posté par alex666 . Évalué à -1.
Ça représente quoi, ce machin? Un SSD? Une plaque de cuisson? Gogol drive? pas très figuratif!
Je persiste à penser que mon scribe avec son
bourrinburin est plus explicite (sous réserve que l'histoire soit encore au programme dans 10 ans, ce qui n'est pas gagné)[^] # Re: A quand une IHM révolutionnaire ?
Posté par Maclag . Évalué à 5.
C'est exactement pour ce genre de truc que les vieux cons dans mon genre ne veulent pas remplacer le logo de disquette: c'est le même dans toutes les applis et on le connaît bien.
Ce machin ci-dessus, je dirais comme le commentaire au-dessus: on ne sait pas trop ce que c'est (appuyez sur un gros bouton gris??) et c'est uniquement sous Gnome, donc très loin d'être universel.
On ne peut plus se mettre d'accord sur les logos et symboles à plusieurs en réfléchissant à l'ergonomie?
Freedesktop, c'est mort et enterré??
[^] # Re: A quand une IHM révolutionnaire ?
Posté par antistress (site web personnel) . Évalué à 5.
J'en parlais il y a un moment ici
http://libre-ouvert.toile-libre.org/?article145/pas-de-bonne-icone-sans-bonne-metaphore
[^] # Re: A quand une IHM révolutionnaire ?
Posté par trancheX . Évalué à 3.
Je pertinente cet article, et j'ajouterai une petite anecdote sur le logo de la disquette :
En rangeant chez mes parents avec mon cousin, qui a une dizaine d'années, on est tombé sur un tas de disquettes et sa réaction m'a vraiment fait prendre conscience que j'étais devenu vieux, il a dis : "c'est marrant, c'est comme le logo pour sauvegarder" …
Et finalement je penses que si on montre une disquette à des enfants qui ont déjà manipulé un ordinateur ça serait très logique qu'ils aient tous cette réaction.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par windu.2b . Évalué à 3.
En 2012, on avait demandé à un apprenti d'installer les nouveaux drivers sur un (trèèèèèès) vieux serveur[*]. Pour ça, il devait les télécharger sur le site du fabricant, les copier sur une disquette, puis donner la disquette à manger au serveur.
1h après, il revient nous voir, nous disant qu'il arrive pas à copier sur la disquette. L'apprenti (18-19 ans, à l'époque) ne connaissait pas le verrouillage en écriture des disquettes !
[*] Le serveur n'était pas en prod' : on l'avait ressorti de la naphtaline, pour l'occasion.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Albert_ . Évalué à 8.
Bonne blague :)
Le coup des disquettes me rappelle une petite anecdote:
Mon fils rentrant dans la voiture de son grand-pere demandant "c'est quoi ce trou dans ta voiture".
"C'est pour ecouter la musique"
"Ah c'est un lecteur mp3"
"Ah non c'est un lecteur cassette"
"c'est quoi une cassette?"
Et ben la on s'est tous pris un coup de vieux et pas que le grand-pere!
[^] # Re: A quand une IHM révolutionnaire ?
Posté par abakkk . Évalué à 4.
Dans notre quotidien, dans l'espace public, etc, il y a tout un tas de symboles graphiques qui ont perdu depuis longtemps, parfois plusieurs siècles, le lien avec l'objet représenté et son contexte. Est-ce que ça pose un problème ? Non, bien au contraire, c'est un élément culturel comme un autre. Dans un siècle, si l’icône de la disquette a perduré jusque là, personne ne pensera à le remettre en cause.
On peut remplacer les icônes par du texte mais là encore c'est la même chose. L'étymologie d'un mot est liée à un usage à un moment donné.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Renault (site web personnel) . Évalué à 3.
Puis cela fait entrer la problématique de la traduction du logiciel. Domaine délicat.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Alex G. . Évalué à 2.
Oui et ce qui justifie une icône c'est surtout c'est surtout le fait que notre cerveau est très rapide à repérer une image, bien plus qu'à lire un texte.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Psychofox (Mastodon) . Évalué à 7.
Cette masturbation mentale sur les icônes me fait assez marrer dans un monde "mobile" où les icônes sont maintenant de plus en plus mises à l'écart pour un retour au texte. Parce que bon si tu regardes les app mobiles t'as maxi 2-3 icônes sur un seul écran et si tu veux des trucs plus avancés tu dois passer par un menu…avec du texte.
D'ailleurs cette histoire de sauver un fichier c'est aussi un concept complètement périmé. Dans la mesure du possible (la question de la volumétrie est essentielle) un fichier devrait être sauvegardé de façon quasi synchrone. On ne devrait plus chercher à sauver un fichier mais à le publier.
Ce qui compte ce sont les commits et ça même le grand public est maintenant habitué à la notion de versionning, checkout, checkin(commit) à force d'utiliser des GED en entreprise.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Olivier ROSET (site web personnel) . Évalué à 9.
Ta notion du "grand public" me laisse dubitatif. ;)
Sérieux ?!?
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Maclag . Évalué à 10.
Mais ce n'est pas tout, grâce à l'intégration d'Ubuntu dans Windows, le grand public sait maintenant aussi utiliser la ligne de commande et maîtrise le bash, awk et sed.
Et grâce à "l'apprentissage du code" à l'école, il peut aussi écrire des pilotes Linux à partir de reverse-engineering du matériel mal ou pas supporté.
Malheureusement, ça annonce aussi le début de la fin pour les environnements tels que Gnome et KDE alors que le grand public se tourne massivement vers i3 et les applications légères, bien plus pratiques pour un usage grand public.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Quand il parle de "grand public" qui fait des commits/du versionning, ça me fait penser aux gens dans les bureaux (donc pas le grand grand public, mais quand même pas mal de monde) qui nomment leurs fichiers
nom-de-fichier-30-01-2017.odt
, en gros avec une date. Cela leur permet de revenir en arrière à divers points dans le temps s'ils ont fait une erreur, effacer des trucs sans trop de peur, etc. C'est un peu le commit du pauvre quoi. Ces gens font du versionnement sans s'en rendre compte. C'est d'ailleurs assez marrant car il me semble que la plupart des logiciels de traitement de texte et tableur ont du versionnement intégré de nos jours (on peut faire des snapshots directement dans le même fichier), mais très peu le savent/l'utilisent. Tiens encore y a quelques jours, pour un projet quelqu'un m'a donné un fichier tableur imprimé et le nom du fichier était noté en haut de page. Sans surprise, la date était dans le nom de fichier. Bon ensuite je sais pas si c'est de cela qu'il parle (première fois que j'entends parler de "GED" mais un tour sur Wikipédia me fait dire que c'est autre chose).On va aussi faire des commits en modifiant des images. Les personnes habituées, voire qui ont déjà perdu des données, vont souvent sauvegarder leur travail à diverses étapes.
Etc.
Donc il n'a pas tout à fait tort, même si je ne dirais pas que c'est tout le monde non plus. Quant à automatiser cela pour les gens, l'exemple du traitement de texte/tableur est assez symptomatique du fait que même lorsque les fonctionnalités existent, les gens ne les utilisent pas forcément. Ils reviennent aux bases qu'ils connaissent: diverses versions du même fichier côte à côte et visible dans un répertoire.
Au moins un des designers GNOME (Jimmac) pense aussi ainsi, du moins y a un an, la dernière fois qu'on s'est vus. On a eu une discussion à ce sujet et perso je ne suis pas convaincu. Ne pas avoir de concept de "sauver les fichiers", c'est aussi ne pas avoir de concept de répertoire, voire de ranger tout court, ni de nom de fichier. En gros, y a plus vraiment de concept de fichiers. Pour moi, les téléphones sont l'exemple parfait de cela car c'est la première tentative réelle de la disparition du concept de fichier. Au final, les gens font constamment des photos par exemple, et le jour où ils veulent t'en retrouver une, ils se mettent à scroller comme des malades: "attends, c'était y a pas longtemps. Hmmm… je pense que c'est avant d'aller ici… ah attends j'ai dû passer, c'était clairement après ça…" (au bout de 10 minutes, soit ils ont trouvés, soit ils ont abandonnés en te disant que de toutes façons, c'était pas si important). Franchement c'est pas un type d'organisation des données que je veux voir apparaître dans mon ordi principal.
Cela ne peut marcher qu'avec une certaine rigueur, en taggant ses données immédiatement dès qu'on la crée. Mais au final tagger pour recherche ultérieure ou sauver avec un nom de fichier et dans un répertoire donné, quelle différence? Très vraiment. Si on se souvient plus comment on a taggué, on retrouvera pas la donnée, de même que si on se souvient plus on l'a mise. Dans les deux cas, un peu de rigueur est nécessaire.
Alors j'espère qu'on ne verra pas ces disparitions de concept trop rapidement dans GNOME. Ensuite je peux être surpris, qui sait! Peut-être arriveront-ils à le faire avec un design génial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 5.
n dimensions vs. une dimension. Ma facture Paypal pour mon achat d'un téléphone, je la mets dans le dossier Paypal avec tous mes paiements Paypal ou dans mon dossier Téléphonie avec les factures d'opérateurs etc. ?
Et puis pour retrouver la photo que tu cherches, avec ton explorateur de fichier sur ton téléphone, au lieu de scroll la galerie en te souvenant "mmmh ça doit être après", tu vas… scroll en regardant les "IMG_2017_06_blah.jpg" et… bah tu vas te dire "mmmh ça devait être après", et tu liras même pas les noms de fichiers en fait, puisque regarder les miniatures sera bien plus parlant. Tu viens de revenir au point de départ.
Ou alors tes images ne s'appellent pas "IMG_date.jpg" mais "Voyage-Bali-avec-beaux-parents-012.jpg", mais par quelle magie ? Je doute que ton appareil photo le fasse tout seul. Donc tu les as renommées à la main. Bravo tu viens de réinventer les tags en moins bien. Tu peux mettre des tags au lieu de renommer les fichiers, en tapant les mêmes mots, et revenir au soft de galerie au lieu de l'explorateur.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par RyDroid . Évalué à -4.
Et le lien symbolique fut inventé !
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Ah oui super pratique, au lieu d'une appli de gestion de fichier multimédia où je tag "tatie Janine" et "La Baule" je claque du
ln -s
euh dans quel ordre déjà.On passera sur la super suggestion de lien symbolique donc quand je veux supprimer ma photo, suivant par où je suis entré pour la trouver, soit je la "détag" en supprimant le lien, soit je la supprime pour de bon (et je pète les liens).
Non vraiment, changez rien, je vois déjà Apple et Google frissonner.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par dinomasque . Évalué à 6.
BeOS faisait ça très bien nativement il y a 20 ans : tu taguais ton fichier (photo, son, document, …) directement depuis le gestionnaire de fichier et l'OS permettait de trier/filtrer par metadonnées.
C'était géré au niveau du système de fichiers.
Mais bon, c'était il y a seulement 20 ans, il faut laisser le temps aux autres de rattraper ce léger retard.
BeOS le faisait il y a 20 ans !
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Si BeOS le faisait il y a 20 ans, il faudrait que tu mettes ta signature à jour ;)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Maclag . Évalué à 10.
BeOS mettait les signatures à jour tout seul il y a 0x1F ans! Par contre il y avait un bug.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par RyDroid . Évalué à 0.
Rien n'empêche de faire une interface graphique pour cela, ça existe même probablement déjà.
Certes, au moins la majorité des systèmes de fichiers n'ont pas été pensés pour être multi-dimensionnels. Mais pour ceux qui supportent les liens symboliques, ils peuvent l'être, même si ça pourrait être mieux.
On peut aussi imaginer une option de suppression du fichier et de tous les liens symboliques associés. Ça rajoute un concept de "super suppression", mais ça change beaucoup moins qu'un tout nouveau système d'étiquettes. Adapter une application pour appeler une fonction "super suppression" au lieu d'une fonction de suppression simple, c'est beaucoup plus facile que de l'adapter à gérer un système d'étiquettes (et encore s'il n'y en a qu'un).
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Je ne suis pas forcément d'accord. Ce n'est pas parce que tu abolis la notion de sauvegarde de fichier que tu ne peux pas définir l'emplacement de ta donnée lors de la création.
Un exemple bête si je crée un trousseau keypass sur mon smartphone android je lui donne son nom (de fichier) et son emplacement (/mnt/sdcard/keepass/montrousseau.kdbx) mais à chaque nouvelle entrée c'est lui qui fait la sauvegarde. Dans le cas de keypass c'est relativement simple dans le sens où quand tu sors du "formulaire" de création/modification d'une entrée l'appli sait qu'elle peut sauvegarder. Dans le cas d'un traitement de texte ou outil de manipulation d'une image t'es obligé de te baser sur une intervalle de temps ou de nombre de modifications.
Mais bon après j'ai l'habitude de synchroniser mes données sur un stockage qui snapshot de façon régulière, et j'utilise git pour plein de trucs du coup ouais ça me gave de faire des :w et ctrl+s pour sauvegarder alors que je peux revenir à un instant t - x en toute facilité et fait des commits + push quand un changement est considéré comme validé :)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par robin . Évalué à 1.
Pour :w, tu peux l'automatiser avec une autocommande qui se déclenche en cas d'inactivité ou à chaque fois que tu sort du mode insertion (et avec undo-tree ou autre plugin pour avoir une vue en arbre des undo + histedit à 10000 ou plus, tu ne peux pas perdre de donnés de toute façon).
bépo powered
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 5.
Pour les photos, les données Exif (surtout sur les téléphones) contiennent la date précise et les données GPS. Avec l'intelligence artificielle, on a également la reconnaissance d'objets, de lieux, de visages… Chez Apple et Google, avec leurs assistants, on commence déjà à pouvoir demander les photos de Noël dernier, de tel voyage, avec telle personne.
Pour le moment, les technos ne sont pas encore totalement au point et on est dans une période de transition, mais d'ici quelques années, on devrait avoir la même chose que dans le film Her (que je vous conseil chaudement).
Par contre, la mauvaise nouvelle, c'est que le libre semble complètement à la ramasse dans ce domaine, puisque il ne semble pas y avoir les prémisses d'un début d'assistant personnel libre et on ne semble pas non plus trop se pencher sur les IA.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 27 septembre 2017 à 19:14.
Tout ce que vous dites tous est vrai. Mais pour moi, toutes ces choses là viennent en complément d'une organisation classique. Les reconnaissances de visage fonctionnent bien mais ne sont pas parfaites. Les dates sont toujours bonnes sur un portable mais voir une date erronnée sur un appareil photo dont on a enlevé la batterie trop longtemps est encore très courant. Le GPS est dispo sur certains appareils photo haut de gamme (donc cher) mais pas tous, loin de là. La catégorisation automatique (de visage, voyage, sujets, etc.) marche bien mais pas parfaitement. On en sait quelque chose, cela fait des années quand on a tous de la catégorisation dans les emails (antispam) et que les faux-positifs comme les faux-négatifs continuent à apparaître. Et ce, même chez Google (comme chez n'importe quel fournisseur).
Or ces quelques faux-positifs et négatifs même s'il y en a juste quelques uns sont déjà quelques uns de trop. Si tu demandes toutes les photos de noël avec Tati Marie et qu'il en manque quelques unes car la reconnaissance de visage n'a pas marché bien, ou bien parce qu'elles ont été prises avec un appareil qui n'avait pas la bonne date, ben ce sont potentiellement des photos perdues à jamais (mais qui continuent à prendre de la place sur ton disque) et tu n'en sauras jamais rien. Tu ne peux même pas aller les chercher à la main puisque dans ce monde où tout est taggué et reconnu automatiquement, toutes les photos sont en vrac dans un répertoire (ou plusieurs répertoires créés automatiquement) qui contient donc des milliers voire dizaines de milliers de photos au fil des ans.
Si par contre, après Noël, tu as mis toutes tes photos dans un répertoire
Pictures/2017/12/soiree-noel/
par exemple, ça ne t'empêche pas d'avoir un assistant pour obtenir en un instant toutes les photos de Noël qui montrent Tati Marie, mais alternativement tu peux aussi jeter un œil toi-même dans ton répertoire qui ne contient que quelques dizaines de photos, et les faire défiler en quelques minutes (voire juste regarder vite fait l'aperçu dans le dossier). Garder un contrôle sur tes fichiers et ton organisation ne t'empêche absolument pas de les tagguer, d'avoir de la reconnaissance dessus, d'utiliser les méta-données quand elles sont présentes (et valides), et d'avoir un assistant électronique pour les retrouver. Mais au moins tu peux toujours revenir aux bases.Franchement mes emails, heureusement que j'ai des filtres (créés à l'ancienne pour une gestion à l'ancienne par répertoire) et pas juste une organisation automatique (gmail fait ça maintenant l'organisation automatique, ça marche globalement mais y a plein d'erreurs). De même heureusement que je regarde encore de temps en temps la boîte spam car je retrouve régulièrement des emails valides (encore une fois, sur ma boîte principale auto-hébergée comme sur ma boîte gmail que j'utilise pour des contacts par exemple lorsque je veux pas leur donner mon email principal immédiatement; là par exemple je viens de jeter un œil et j'ai découvert une réponse d'un imprimeur à qui j'avais demandé un devis la semaine dernière! Je pensais qu'ils n'avaient pas répondu mais en fait ça a fini en spam… heureusement que j'ai vu. Et on parle de Google).
Donc oui tous ces assistants, ces catégorisations automatiques, etc. c'est vraiment super cool. Ça aide. Mais ça ne remplace pas l'organisation manuelle à ce jour. En fait je vais même oser le dire: je pense que ça ne remplacera jamais totalement une organisation manuelle pour la simple raison que l'intelligence artificielle… n'est pas de l'intelligence! C'était ma spécialité à l'université et en fait c'est juste des stats principalement. La plupart des algorithmes qu'on trouve extraordinaires (réseaux de neurones, filtres bayésien, modèles de markov cachés… un peu tout type d'algo utilisés en reconnaissance de forme ou en décision…) sont dérivées de théories probabilistes et statistiques. Or s'il y a une chose dont on peut être sûr, c'est que des méthodes statistiques ne seront jamais vraies dans 100% des cas; mais dans la plupart, oui. C'est un peu la définition même de ce que sont les statistiques.
Alors certes je n'ai plus vraiment étudié l'IA depuis la fac. Qui sait, peut-être que dans certains labos, ils sont super proches de donner la conscience aux IAs qui penseront vraiment d'elle même et pas avec des stats (mais ce jour là, je suis pas sûr qu'elle seront jouasses d'être nos "assistants personnels", nos esclaves en somme). Si ça arrive, j'aurais eu tort. Car à ce jour, je ne crois pas que ça puisse arriver, justement car j'ai vu, étudié et implémenté ce genre de trucs et que pour moi, c'est tout sauf intelligent (enfin les humains qui ont créé ces systèmes sont intelligents, pas les logiciels). Et je doute vraiment qu'on arrive un jour à créer une vraie conscience (je sais, c'est à la mode de dire l'inverse et d'avoir peur de la révolte des ordis).
Conclusion: oui à tous ces trucs pour nous aider, mais non ça ne remplace pas une organisation humaine en plus en tous cas dès que les données sont considérées un tant soit peu importantes et qu'en perdre un peu régulièrement n'est pas acceptable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 2.
Ta classification manuelle à base de dossiers est juste un sous-ensemble restreint de ce qu'il est possible de faire avec des tags, tu peux le retourner comme tu veux. Sur l'immaturité de la classification automatique, je suis d'accord. Mais quand tu mets toi-même ta photo dans le répertoire "Noël", met-lui le tag à la main, c'est encore plus simple (pas la peine d'aller chercher le répertoire dans le sélecteur de fichier, tu tapes direct "Noël") et en plus tu pourras même mettre d'autres tags.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Dans la théorie tu as tout à fait raison.
Dans la pratique, avoir une organisation temporelle simple devant les yeux (classer les données par années et mois, et à l'intérieur par évènements dans mon cas; dans le cas de quelqu'un d'autre ça peut être une autre organisation, du moment que ça a un sens pour la personne, c'est ce qui compte; chacun son truc) me permet de retrouver des données auxquelles je pense plus (mais ça veut pas dire qu'elle ne m'intéressent pas; on oublie, même des choses qu'on aime!). C'est simple, c'est clair et surtout c'est visuel. Des tags, c'est une sorte de trucs un peu brouillard. D'ailleurs c'est marrant car la représentation visuelle la plus classique, c'est… un nuage de tags! Comme quoi… Souvent on va mettre en plus gros les tags les plus utilisés, mais cela n'est pas utile pour chercher. On ne cherche pas forcément ce qu'on fait le plus (cette représentation est plus utile pour les tiers qui veulent savoir les trucs dont tu parles le plus, donc bien dans un blog, mais pas pour soi).
Combien de fois j'ai cherché des trucs et je me dis, c'est quoi comme tag que j'ai mis? J'en essaie 2 ou 3 avant de trouver le bon. Le truc, c'est que dans la vie, on a plus que 3 ou 4 catégories à retenir. On en a des centaines. On se souviendra seulement de comment on taggue les trucs les plus courants qu'on fait quotidiennement. Mais sorti de là, c'est… le brouillard! Quand j'ai des dossiers physiques dans des classeurs, j'ai pas besoin de mémoriser le titre du classeur. Je sais qu'il est placé vers la droite de mon armoire, je lis 2 ou 3 titres, je le trouve, je le sors, et dedans j'ai rangé les choses par date ou alphabétiquement ou autre. C'est facile et je trouve ce que je cherche. Dans des dossiers numériques, c'est pareil. Si tous mes fichiers sont taggués par contre, ça m'obligerait à essayer de me souvenir des tags précis des milliers de trucs que je fais, dont certains une seule fois dans ma vie.
Le truc classique, c'est aussi d'avoir plusieurs tags qui sont en fait les mêmes car on se souvient pas bien de ce qu'on a écrit les fois précédentes (logiciels libres, logiciel libre, free software, FOSS, FLOSS… autant de variantes que je pourrais utiliser!). Franchement les blogs sont toujours plein de duplication de tags légèrement différents. Sans compter les fautes d'orthographe or de typo. Si en tapant vite, j'inverse des lettres, genre "onël", dans mon répertoire 2017/12/, ben quand je chercherai mes photos, je comprendrais tout de suite que c'était une typo, je corrige puis je regarde mes photos (ça ne m'a pris 1 seconde de plus pour corriger). Si les tags sont le seul moyen de retrouver mes photos par contre, je tape "noël 2017" et là… rien! Hop je me dis, ça y est, j'ai perdu les photos. Peut-être que je peux essayer de les retrouver en jouant avec d'autres tags, et avec un peu de chance je les récupère toutes et corrige tous les tags, mais ce sera pas juste quelques secondes que j'aurais perdu. Probablement plus 30 minutes.
En fait, si un jour les assistants personnels sont réellement intelligents, c'est moins grave. On n'a plus besoin de mémoriser le tag précis. On dira "je suis allé voir ce spectacle le mois dernier, tu peux me le retrouver", et il te retourner le truc taggué "danse" car c'était un spectacle de danse. Ou il corrigera tes fautes d'orthographe et de typo. Mais comme je l'ai dit, je ne crois pas que l'IA deviendra réellement intelligente un jour. On peut essayer de faire corriger des mots avec des dictionnaires et en comparant des distances de mot; on peut créer des catégories sémantiques; on peut améliorer de plein de façon après coup en découvrant les limitations au fur et à mesure. Mais ça ne sera jamais parfait. Enfin c'est ce que je pense. On verra dans 10 ans.
Quoiqu'il en soit, ce sont des trucs cools à étudier, à développer et à utiliser. Mais à ce jour, ça ne remplace pas mon organisation personnelle des fichiers. Ça la complète éventuellement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 6.
Ca tombe bien, j'ai en gros jamais vu ça ailleurs que sur des blogs (ou sites corporate ou… enfin bon, blog d'un tiers en gros).
Mais, euh, quand tu les as mis dans des dossiers, par quelle magie te souviens-tu du nom du dossier (et de son chemin…) mieux que de celui d'un tag ?…
Parce que tu n'as que 5-6 classeurs. Limite-toi à 5-6 tags et…
Et tu pourras mettre un article dans ton dossier FLOSS alors que tu as un dossier FOSS, je vois pas la différence. Et tu pars du principe que le système de tagging (qui remplacerait, en plus simple niveau UI qui plus est, un sélecteur de fichier) ne t'aiderait absolument pas. Il y a plusieurs degrés d'"intelligence" (proposer FLOSS quand tu as tapé le F ; proposer FLOSS par proximité quand tu as tapé FOSS ; proposer FLOSS quand tu as tapé "logiciel libre" par des heuristiques dispos dans le moindre projet pourribidon d'"IA" sur github…) pour te faciliter la vie encore mieux que Dolphin.
Franchement j'arrête là, je vois pas l'intérêt de continuer. Tu es très courtois et même ouvert en théorie à l'idée des tags, mais je sais pas pourquoi (enfin j'ai une idée) tu ne veux surtout pas avoir tort et lâcher ton système dont presque plus personne ne veut (je pense pas être un fanboy des GAFA si on se renseigne un peu, pourtant je te contredit sur ce point…) donc je vais arrêter d'insister avant que ça devienne trop lourd.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par abakkk . Évalué à 3.
C'est un sous-ensemble "universel". Reviens dans 10 ans sur des fichiers archivés, les seuls tags que tu comprendra seront les noms de fichier et les répertoires.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 1.
Hein que quoi ?
"photo_tata_janine.jpg" je le comprendrai mais "Tata Janine" sur un fichier de type "photographie" je le comprendrai pas ? Mais qu'est-ce que tu racontes ?
Ou alors tu parles du cas où le format de stockage des tags est propriétaire, mais alors quel rapport avec la discussion ? C'est parfaitement orthogonal. Si ton format de tags est documenté aucun problème, et inversement si ton FS est proprio si dans 10 ans tu n'as plus les specs, tu auras un truc incompréhensible (potentiellement obfusqué) à la place de "photo_tata_janine.jpg".
[^] # Re: A quand une IHM révolutionnaire ?
Posté par flan (site web personnel) . Évalué à 7. Dernière modification le 02 octobre 2017 à 23:02.
Oui, c'est vrai, en théorie…
En pratique, cela se matérialise par deux processus qui n'ont rien à voir.
Tu déplaces ton fichier de dossier en sous-dossier, et en toute logique tu vas du plus général au plus précis (si tu as une arborescence du type ~/Documents/Administration/Impôts/2017/Revenus/, par exemple. Et tu ne fais ça qu'une fois ! De plus, quand tu fouilles, cette même arborescence aide beaucoup. Si l'arborescence que je consulte est du type ~/Documents/Administration/Finances/Revenus/2017 , je mettrai exactement le même temps pour trouver mon document.
Avec des tags, je vais devoir taper successivement "documents", "administration", "impôts", "revenus" et "2017", mais il faut aussi que je me souvienne quels tags j'ai mis sur tous les autres documents du même type. Est-ce que j'ai mis "revenus" sur l'année dernière ? ai-je mis "taxes", "dgfip", "IR" ?
Et que faire quand je veux fouiller un peu dans mes documents ? Je liste les tags un par un ? je vais revoir 50 fois les mêmes documents (et ça va exploser avec le tag 2017 ou 2016).
J'ai une liste numérique de tous mes bouquins physiques, qui permet notamment de spécifier le genre littéraire du livre (les infos sont récupérées d'entre autres Amazon, mais le genre est souvent fantaisiste), qui fonctionne par tags. Au final, quand j'ajoute un nouveau livre d'un auteur dont j'ai déjà d'autres livres, je suis obligé, systématiquement, d'aller vérifier quel genre j'ai attribué aux précédents pour avoir quelque chose de cohérent.
Bref, je ne crois vraiment pas aux tags comme unique système de tri, même si ça peut être utile quand c'est déterminé de façon automatique (par exemple en fonction du contenu ou des méta-données — ça fonctionne très bien avec les mp3) et constante (pas de synonyme), ou au moins par vague (appliquer le tag à plein de fichiers d'un coup).
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Alex G. . Évalué à 2.
Il y a les thesaurus (hiérarchies de tags) qui permettent d'avoir l'arborescence. Le problème c'est qu'on sort de la simplicité (mais peut être y a moyen d'y suppléer).
Moi (suite à la lecture de A city is not a tree, j'aime beaucoup cette notion de demi treillis, qui est celle que l'on retrouve dans un diagramme de classe avec héritage multiple, qui je, trouve, capture pas mal de choses à la fois.
Mais sinon j'aime bien les tags pour le fait qu'on puisse en mettre plusieurs. Je pense que le fait d'être à l'aise avec l'un ou l'autre correspond plus à un type d'orientation mentale.
Un des limitation des tags aussi c'est qu'ils capturent mal la polysémie d'un mot (à l'utilisateur de la gérer).
[^] # Re: A quand une IHM révolutionnaire ?
Posté par alex666 . Évalué à -2.
En conséquence de quoi l' "intelligence" artificielle reflète surtout la pauvreté intellectuelle de ses financeurs (ohé, MZ et autres) et de l'état de l'art (mais là, ce n'est pas (toujours) la faute des chercheurs du domaine)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par ff9097 . Évalué à 1.
Un fichier de bureautique versionné doit être beaucoup plus lourd quand même. Mais je suis d'accord avec le principe, il faut juste avoir confiance a la robustesse du système de versionnage (fichier corrompu par exemple).
Pour l'histoire des photos c'est par contre un assez mauvais exemple dans la mesure où personne ne renomme ces photos numériques. On se contente d'un classement par dossier (équivalent aux albums sur mobile).
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Maclag . Évalué à 5.
Je sais ce que c'est que le versioning, je sais qu'il est présent dans MS Office, et je ne m'en sers pas:
Sauver avec un nom de fichier daté, ça te garantir surtout de récupérer quelque chose quand tout se casse la gueule et que le fichier sort corrompu.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Albert_ . Évalué à 1.
C'est rigolo, la recuperation de fichier de Libreoffice marche tres bien (jamais eu de fichier corrompus)…
Enfin bon git et sphinx ou latex pour faire des docs cela marche particulierement bien…
[^] # Re: A quand une IHM révolutionnaire ?
Posté par whity . Évalué à 1.
Heureux homme que tu es. Moi j’en ai eu, que j’ai dû réparer à la main (le format xml a au moins cet avantage là, ça se fait relativement facilement). Et ce alors que le fichier avait été enregistré proprement…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Albert_ . Évalué à 2.
C'est peut etre que je ne l'utilise plus autant que avant.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Je suis d'accord avec le début de l'analyse mais moins avec la fin :
* la disquette : on peut en voir chez moi, elles me servent de sous-verres à l'heure de l'apéro. Ce n'est pas fragile et on peut les laver.
* le disque dur : très peu de personnes en ont vu et les SSD les remplacent de plus en plus. On ne les reconnait que grâce à leurs étiquettes.
* Le dossier papier dans une chemise, c'est un truc du passé. Le mot fichier a perdu tout lien avec le mot fiche et l'ensemble de fiches mises dans une chemise en papier cartonné. Il y a des lustres que je n'en ai plus acheté. Le symbole proposé est obsolète lu aussi.
Alors, il n'y a pas de solution si on considère qu'un dessin doit évoquer quelque chose de physique alors que les concepts sont de plus en plus abstraits. Par conséquent, je pense que la meilleure option est de conserver les icônes actuelles. L'enfant qui voit une disquette et dit qu'elle ressemble au symbole enregistrer a complètement raison. Le symbole est connu, il correspond à une action, à un concept indépendant de toute réalité physique.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sufflope (site web personnel) . Évalué à 4.
Je pense que quand on en est au point où on réfléchit à l'avenir du rapport technologie-homme à l'échelle de la planète, et que l'argument c'est "j'utilise des disquettes comme dessous de verre pour l'apéro" on peut arrêter la discussion et commander des chrysanthèmes.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Olivier ROSET (site web personnel) . Évalué à 1. Dernière modification le 27 septembre 2017 à 10:59.
Euh, où est-ce que je met en avant les icônes dans mon message?
Je désire voir apparaître autre chose justement. C'est là la difficulté.
Inventer une nouvelle représentation de l'espace de travail utilisateur en essayant d'introduire de nouveaux modes de représentation des actions, objets, applications, etc. :)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par abakkk . Évalué à 0.
Créer une représentation pour un nouvel usage est une chose, modifier une représentation qui est comprise de tous ça en est une autre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Est il prévu de rendre la session Wayland "crashproof"
Posté par trancheX . Évalué à 8.
Je n'ai pour l'instant jamais utilisé Wayland mais ce genre de bug ne m'y encourage pas vraiment.
Pour résumer (et corrigez moi si je m’égare) : avec X11 le x11-server était plutôt stable (je ne me souviens pas l'avoir vu planter) donc le gestionnaire de fenêtres qui plante n'est pas un gros problème : il se relance et comme toutes les applis sont attachées au server-x11 tout repars comme avant.
Mais avec Wayland le gestionnaire de fenêtre devient aussi x11-server-équivalent et donc un plantage de celui ci équivaut à la perte de toutes les applications en cours et donc du travail en cours.
Hors le gestionnaire de fenêtre de Gnome (Gnome-shell) utilise beaucoup de technologies un peux risqué, genre javascript, ce qui est très bien pour l'étendre et ajouter des extensions etc, mais aussi ce qui le rend plus dépendant au niveau de la stabilité : stabilité du code C plus du moteur JS plus de toutes les extensions.
Alors même si je ne doute pas des compétences des développeurs Gnome/RedHat et que donc les plantages de Gnome-shell seront extrêmement rare, je serais quand même plus tranquille si Gnome-shell était "crash-proof".
Il y a plusieurs idées lancés dans le bugzilla pour résoudre le problème, mais par contre je n'ai pas l'impression qu'il y ai une solution choisie ni un début de travail/réflexion sur ce point.
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par Renault (site web personnel) . Évalué à 7.
Euh, je n'ai jamais vu un crash graphique de X11 où tu récupérais tes applications comme avant.
Mais certes, depuis GNOME 3, si GNOME merde sous X11, il se relance et tout va bien.
Mais si pour Wayland ce n'est pas encore le cas, c'est prévu à terme : https://fedoraproject.org/wiki/Wayland_features#Restarting_gnome-shell
Après, GNOME reste très stable au quotidien, je ne trouve pas que cette absence soit vraiment bloquante. J'utilise Wayland depuis 2 ans maintenant avec GNOME.
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par trancheX . Évalué à 4.
Oui c'est ce que je dis : X11 ne plante quasiment jamais donc toutes les applis survivent à un plantage du gestionnaire de fenêtres Mutter/Compiz (je viens de tuer mon compiz pour vérifier: aucun soucis).
Par contre avec Wayland un plantage de Mutter/Gnome-Shell c'est comme un plantage de X11. Ce que je n'ai jamais rencontré, et qui est beaucoup plus embêtant qu'un Compiz qui par en vrille (rarement).
Sinon merci pour le lien, ça veut dire que c'est quand même dans les "pending features". J'ai peur qu'ils doivent ré-écrire pas mal de code de gnome-shell pour y arriver mais c'est bien que ça soit pas juste un "wontfix".
2 ans ! Wouha je suis beaucoup plus prudent pour ce genre de chose (je laisse lâchement les autres essuyer les plâtres sur des composants critique comme ça).
Donc effectivement ça semble très peu nécessaire, mais je suis quand même déçu que les développeurs Gnome-Shell n'y aient pas pensés dès la conception.
Ce qui m’ennuie un peu c'est qu'on peut très bien ne pas avoir de soucis puis suite à une maj/installation d'une extension de Gnome-Shell des soucis commencent à apparaitre, et avec l'architecture actuel c'est quand même potentiellement du gros soucis.
[^] # Et synergy ?
Posté par François GUÉRIN (Mastodon) . Évalué à 3.
J'utilise synergy pour partager clavier / souris entre 2 machines (je suis en train de taper du texte sur mon clavier de desktop, le texte s'écrit sur le laptop en ce moment…), et avec wayland, ça ne marche pas dans : session X11 obligatoire…
Synergy est un soft super, mais X11 only pour le moment : tant qu'il ne sera pas supporté dans wayland, pas de wayland pour moi : c'est juste indispansable de pouvoir copier-sue-le-laptop > coller-sur-le-desktop !
Sinon, GNOME déchire sa race… j'adore !
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à -8.
J'ai bien peur que cela ne marche jamais. Avec wayland on a deja perdu la capacite des faire des photos d'ecran alors le partage de clavier et souris ouh la la.
D'ailleurs je trouve curieux que personne n'ai fait remarque que derriere la "securite" wayland c'est en fait les DRM et l'impossibilite de faire des captures de films (par exemple).
[^] # Re: Et synergy ?
Posté par Renault (site web personnel) . Évalué à 10.
Tu peux faire des captures d'écran, mais pas avec n'importe qu'elle application ou n'importe comment. Car cela pourrait servir dans le cadre d'un piratage.
Donc il faut une application autorisée pour l'instant pour le faire. De ce que j'ai compris à terme n'importe qu'elle application pourra le faire, l'utilisateur n'aura qu'à valider cette autorisation à l'usage (comme pour les applications des téléphones).
Cela évitera qu'une application le fasse en douce quand elle le veut sans que l'utilisateur ne le sache.
Et c'est en effet prévu ces histoires de mutualisations des entrées / sorties. Mais cela prend du temps.
L'application peut lire et écrire dans son buffer graphique comme elle veut. Si GNOME Vidéo veut copier le film qu'il lit, Wayland ne pourra pas l'en empêcher. Par contre GNOME Vidéo ne pourra pas le faire via Firefox du moins à son insu et sans mécanisme conjointe. La vraie sécurité impose des contraintes. Mais peut être que le temps du X11 le keylogger suprême te manque.
[^] # Re: Et synergy ?
Posté par Christophe . Évalué à 4.
Dans Wayland, une application n'aura à priori accès qu'à ses ressources, qu'à son affichage. Mais toutes les possibilités sont ouvertes…
Le protocole est extensible: rien n'empêche GNOME Shell de proposer une extension de capture d'écran (avec autorisation en liste blanche de l'utilisateur par exemple) qui sera utilisée par un client Wayland adapté à cette extension. Ce ne sera pas standard (ça reste spécifique à GNOME), mais pour un environnement donné ça peut dépanner.
Par exemple il existe des applications de capture d'écran sur SailfishOS, qui se base pourtant sur un vieux Wayland…
[^] # Re: Et synergy ?
Posté par xcomcmdr . Évalué à 0. Dernière modification le 26 septembre 2017 à 15:00.
Je sais bien que tu détestes absolument wayland.
Je sais que tu ne manques pas d'attribuer tout manque (réel ou supposé) de wayland par rapport à Xorg à de la malice.
Que tu ne manques pas de mettre sécurité entre guillemets, comme si la capacité de keylogger X11 à tour de bras n'était pas une putain de faille de sécurité béante de nos jours.
Mais comparer la sécurité qu'apporte wayland à une DRM c'est franchement BAS et DÉGEULASSE !
PAUVRE TYPE !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à -4.
Et ben tu as oublier les medocs? Parceque la tu as fait fort dans le petage de plomb.
On dirait du Trump.
[^] # Re: Et synergy ?
Posté par Sufflope (site web personnel) . Évalué à 5.
Je ne sais pas par quelle magie mais ça a l'air de pas si mal marcher que ça, la capture d'écran sous Wayland :
Mieux que le restart de gnome-shell, en tout cas.
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à -2.
Quelle application? Parce-que je viens d'essayer et avec Gimp cela ne marche pas.
[^] # Re: Et synergy ?
Posté par Renault (site web personnel) . Évalué à 5.
GNOME Screenshot.
Ce n'est pas comme si j'avais écrit un commentaire à ce sujet.
[^] # Re: Et synergy ?
Posté par Solareagle . Évalué à 1.
Effectivement GNOME Screenshot fonctionne très bien ici. Sauf si vous pensez à des fonctionnalités avancées, la capture se fait en un seul clic. Je suis sous Fedora 25 avec donc GNOME et Wayland.
[^] # Re: Et synergy ?
Posté par Sufflope (site web personnel) . Évalué à 3.
Euh je ne savais pas que GIMP faisait "preneur de capture d'écran". J'ai juste appuyé sur le bouton
PrtScr
de mon portable.[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 1.
Je n'ai pas printscr sur mon portable et oui gimp faisait des screenshots.
[^] # Re: Et synergy ?
Posté par Sufflope (site web personnel) . Évalué à 5.
Les seuls ordis sans bouton ImpEcr que j'ai vus sont ceux d'Apple. Je sens qu'on va apprendre un truc sacrément intéressant sur Albert_.
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 2.
Rate c'est un thinkpad sous Linux sans partition Windows.
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 1.
Thinkpad T460p clavier sans touche prtscr
Il semblerait que les autres marques suivent la pomme dans le "on sort des touches du clavier".
[^] # Re: Et synergy ?
Posté par Sufflope (site web personnel) . Évalué à 10.
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 5. Dernière modification le 27 septembre 2017 à 09:52.
Putain je dois changer mes lunettes…
Je le cherchais en haut…
Mea culpa.
[^] # Re: Et synergy ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 6.
Il faut tout de même avouer que c'est super étonnant de la placer ici.
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 5.
J'ai tout de meme etait nul, ca fait 10 mois que j'ai ce laptop et je ne l'avais toujours pas vu. Bon ca prouve aussi que je regarde pas mon clavier tant que cela :) et en plus quand je fais des screenshots je suis generalement sur le dock avec un clavier entier mais tout de meme j'ai ete nul car j'ai "verifie" hier avant de taper ma connerie…
Comme quoi meme apres des annees LA touche que l'on cherche elle a toujours disparu.
[^] # Re: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
GIMP fait toujours des captures d'écran. Simplement il y a eu un intervalle entre les premiers OS sous Wayland et la mise à jour nécessaire de GIMP pour Wayland (pour être plus précis pour GNOME Shell sous Wayland).
Maintenant c'est implémenté mais ce sera disponible dans GIMP 2.10 seulement.
Dans l'optique sécurité de Wayland, je trouve cette protection assez sensé. En gros, toutes les applications auront le droit de faire des captures d'écran (et pas seulement des applications privilégiées), mais elles doivent passer par une API dbus et ce sera le compositeur (ou Window Manager, je sais pas trop qui a la charge de ça) qui se charge de faire la capture pour l'application. Ce que cela signifie est notamment que l'application n'a pas d'accès direct et ne peut pas regarder l'écran en douce. Il doit "demander". Ce que va faire l'OS alors n'est pas d'interdire mais le faire en avertissant l'utilisateur (que ce soit par une popup, un flash de l'écran, un bruit… quelque chose, libre aux designers de décider). En gros, tu peux plus faire un screenlogger qui va faire des captures régulières de l'écran en "loucedé". On pourra toujours faire des captures, mais simplement si le compositeur/window manager est bien designé, il avertira l'utilisateur.
De même, en cas de capture d'une zone de l'écran, ce sera aussi le compositeur/window manager qui gèrera la récupération de coordonnées. Ainsi typiquement dans l'API de GNOME shell, l'application utiliserait la méthode
SelectArea
, en conséquence de quoi le shell se mettra typiquement dans un mode interactif de récupération d'une zone rectangulaire (classiquement, le curseur change, éventuellement des instructions apparaissent, et l'utilisateur est invité à glisser la souris pour créer une zone rectangulaire). En retour de cette méthode dbus, des coordonnées sont retournées au programme si l'action s'est faite avec succès. Le programme peut alors appeler la méthode dbusScreenshotArea
avec ces paramètres. Il n'y a plus de code dans l'application pour la récupération de coordonnées (puisque l'application n'a plus de visibilité non plus sur sa position dans l'écran et ne peut évaluer cette info) ni pour la prise de capture d'écran ou de zone d'écran elle-même.Je trouve cela plutôt bien. La logique n'est pas d'interdire mais d'avertir l'utilisateur quand des actions à risque sont entreprises (capture d'écran, keylogging, etc.). Certaines choses sont encore impossibles mais cela ne veut pas dire que c'est fait exprès. Simplement que l'API n'a pas encore été écrite.
Pour moi, le seul problème embêtant est que ces APIs ne soient pas au niveau du protocole mais de chaque implémentation. Ainsi GIMP peut bien maintenant faire des captures d'écran sous GNOME Shell, mais pas forcément sous d'autres implémentations au dessus de Wayland. Cela nous obligera à tester diverses APIs jusqu'à ce qu'une marche. J'aurais préféré une API commune.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 2.
Merci de ta reponse c'est assez interessant et confirme bien ce que je dis: wayland n'a pas de possibilite de screenshot. Comme c'est extensible les compositeurs pourront (et gnome est le premier) a implementer un truc pour le faire et on repart vers des API differentes pour faire un truc qui semble assez commun (screenshot et screencast).
[^] # Re: Et synergy ?
Posté par windu.2b . Évalué à 4.
Avec un tel mécanisme (demander la permission au compositeur/Window Manager), on pourrait alors imaginer qu'une fenêtre, apprenant qu'un screenshot est demandé, réponde : "Pas question ! Moi, tu me remplaces par un carré noir, car j'affiche des infos confidentielles" ?
[^] # Re: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Je ne sais pas. Ma connaissance de Wayland est très limitée et s'arrête un peu à ces utilisations de base. Une appli peut/pourra-t-elle demander à ne pas apparaître dans une capture d'écran? Est-ce prévu? Aucune idée. Mais ça pourrait exister, je pense, oui (opinion à prendre avec des pincettes. N'allez pas dire que quelqu'un vous a dit que c'est prévu ou je ne sais quoi! Je ne suis Wayland que de loin).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et synergy ?
Posté par Le Gab . Évalué à 0.
Ça marche sous Fedora 25 avec Gimp 2.8.22.
Petite digression, qu'en est-il d'une API officielle GNOME SHELL pour les extensions?
[^] # Re: Et synergy ?
Posté par Albert_ . Évalué à 2.
Cela ne marche pas sous Archlinux avec Gimp 2.8.22 and Gnome 3.24 wayland.
[^] # Re: Et synergy ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Je me rappelle que quand j'avais testé Wayland, des trucs qui n'étaient pas censé marcher marchaient (mais je ne saurais plus dire quoi). Et quand j'en avais parlé avec un dév Wayland, on me disait que c'était sûrement normal pour une application X (GIMP utilise encore GTK+2, donc n'est pas un client Wayland), qui passait donc par XWayland, ce qui contournait des restrictions Wayland.
Peut-être est-ce ce qui t'arrive et peut-être ce contournement des restrictions a-t-il été corrigé depuis dans les versions suivantes (ce qui explique que d'autres n'ont plus ce comportement dans des versions plus récentes).
J'aimerais bien aussi. Cela fait partie de ces choses où j'ai découvert à GUADEC que certains autres développeurs n'avaient pas du tout la même vision que moi. Pour certains, les extensions sont un hack qui ferait mieux de ne pas exister. Pour d'autres (comme toi et moi), c'est super important et il faudrait donc créer une API stable.
Je pense que la seule chose qui manque est une personne qui prenne le sujet en main, crée une API publique et surtout la maintienne dans le temps. Le fait est que si la plupart des core devs ne considère pas l'API comme devant être publique, alors ils n'ont aucune raison à se faire chier à ne pas la changer quand ils ont besoin.
Ce sont les gens qui font le Logiciel Libre. Tout ce qu'il faut, c'est donc des gens qui poussent dans la direction que tu veux (et ça peut être toi-même!). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et synergy ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
Tout ça devrait arriver avec Pipewire. Comme l'indique Christian Schaller sur son blog :
« Une autre utilisation de Pipewire importante pour nous, était qu'avec la migration vers Wayland, nous savions que nous aurions besoin d'un nouveau mécanisme pour gérer la capture d'écran, puisque la façon dont elle était faite sous X n'était pas très sûre. Jonas Ådahl a donc commencé à travailler sur la création d'une API que nous pourrions prendre en charge dans le compositeur et utiliser Pipewire pour la sortie. Ceci est destiné à couvrir à la fois la capture d'écran, la capture vidéo de l'écran (screencast) et les protocoles distants. Il est important de noter que nous ne nous limitons pas à des protocoles spécifiques comme RDP ou VNC, puisque nous nous sommes assurés qu'il y ait une infrastructure agnostique capable de prendre en charge n'importe quel protocole. Par exemple, nous allons travailler avec l'équipe SPICE de Red Hat pour nous assurer que SPICE puisse tirer parti de Pipewire et de la nouvelle API. Nous nous assurerons également que Chrome et Firefox prennent en charge cette fonctionnalité afin que vous puissiez partager votre bureau Wayland avec des systèmes tels que BlueJeans. »
J'espère que la traduction n'est pas trop catastrophique :)
[^] # Re: Et synergy ?
Posté par trancheX . Évalué à 2.
Tous cela sera bien possible avec Wayland qui n'est qu'un protocole. Le fait qu'on ne puisse pas ré-utiliser les mêmes logiciels de partage/capture d'écran que ceux de X11 c'était un peu dans le cahier des charges de Waland/MIR côté sécurité.
Ma critique/remarque (Gnome-Shell pas crash-proof) se fait uniquement sur l'implémentation de Wayland qui est faite aujourd'hui dans Gnome et qui me semble être une régression par rapport à X11 sur la résistance au crash.
Wayland n'est pas responsable de ça.
[^] # Re: Et synergy ?
Posté par Le Gab . Évalué à 0.
C'est d'ailleurs étonnant qu'il n'y ait pas eu de discussions sur Wayland lors de ce GUADEC car bien que la stabilité ne soit plus à prouver il manque tout de même une API/AccessManagement pour permettre aux applications de type captures d'écrans, partage de périphériques de fonctionner sous GNOME 3/Wayland.
[^] # Re: Et synergy ?
Posté par Renault (site web personnel) . Évalué à 3.
De souvenir ces mécanismes vont reposer sur Flatpak et Wayland lui même. GNOME en tant que tel ne serait pas beaucoup impliqué dans ce processus.
[^] # Re: Et synergy ?
Posté par antistress (site web personnel) . Évalué à 5.
Tout est expliqué dans le projet de dépêche en cours pour la prochaine version de GNOME ;)
[^] # Re: Et synergy ?
Posté par Le Gab . Évalué à 0.
@Sufflope
Ah, effectivement ça marche à présent, je suis pourtant toujours sous Fedora 25 (gnome 3.22.3), du moins pour la partie capture, je n'utilise plus Synergy depuis quelques mois.
@Renaud: Flatpak? Rassure moi, ça ne sera pas la norme voire la condition? Je n'ai aucuns intérêt à utiliser flatpak, je ne suis pas anti, je n'ai simplement aucun usage le justifiant et ni l'envie d'installer 500mo de bazard par flatpak.
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par Sébastien Wilmet . Évalué à 3.
Comme ce commentaire et celui-ci dans le bugzilla l'indique, il n'est pas prévu de rendre gnome-shell sous Wayland crashproof, en tout cas pas à court terme. Matthias Clasen est un des managers de l'équipe desktop chez Red Hat, et gnome-shell/mutter est développé en très grande partie par Red Hat.
Mais à long terme, il y a peut-être de l'espoir, en lisant ce commentaire d'un des développeurs de gnome-shell/mutter.
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par trancheX . Évalué à 0.
Je me réponds à moi même : GnomeShell4 est le projet qui a pour ojectif de résoudre ce problème (+ quelque autres qui sont détaillés sur la page).
C'est une reflection en cours et la soution propre (Option A) nécessitera de ré-écrire une grande partie de GnamoeShell et cassera toute les extensions existante (comme le passage à Firefox version 57).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.